<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<link rel="Stylesheet" type="text/css" href="doc.css" />
<title>Extending the Transactional Editing Domain</title>
</head>
<body>
<h1><a name="top">Extending the Transactional Editing Domain</a></h1>
<p>
Clients that have special requirements in the management of transactions can extend
virtually all aspects of the transactional editing domain API.  As is usual in EMF, the
transaction API defines a number of <em class="CodeName">InteralXyz</em> interfaces
corresponding to the interfaces that are intended for public consumption.  A valid editing
domain implementation must implement the
<a href="../javadoc/org/eclipse/emf/transaction/impl/InternalTransactionalEditingDomain.html"><em class="CodeName">InternalTransactionalEditingDomain</em></a>
interface, a transaction the
<a href="../javadoc/org/eclipse/emf/transaction/impl/InternalTransaction.html"><em class="CodeName">InternalTransaction</em></a>
interface, and a command stack the
<a href="../javadoc/org/eclipse/emf/transaction/impl/InternalTransactionalCommandStack.html"><em class="CodeName">InternalTransactionalCommandStack</em></a>
interface.  Of course, it is highly recommend to extend the default implementations of all
of these interfaces.
</p>

<blockquote>
	<img src="images/extensibility.png" alt="Transaction Extensibility API"/><br/>
	<font size="-2">[<a href="images/extensibility.svg">as SVG</a>]</font>
</blockquote>

<p>
The <em class="CodeName">InternalTransactionalEditingDomain</em> interface specifies the
transaction lifecycle API, from activating a transaction through to deactivating it,
with the intermediate stage of processing pre-commit listeners and executing their
<a href="triggers.html">trigger commands</a> on the <em class="CodeName">InternalTransactionalCommandStack</em>.
The editing domain also keeps track of which of possibly numerous transactions in a
nested structure on one or more threads is currently active, and implements the transfer
of ownership from one thread to another in the <a href="sharing.html">privileged runnable</a>
mechanism.
</p>

<h2>Transaction Validators</h2>

<p>
The <em class="CodeName">TransactionalEditingDomainImpl</em> class has an associated
<a href="../javadoc/org/eclipse/emf/transaction/impl/TransactionValidator.Factory.html"><em class="CodeName">Factory</em></a>
for the construction of
<a href="../javadoc/org/eclipse/emf/transaction/impl/TransactionValidator.html"><em class="CodeName">TransactionValidator</em></a>s.
For each root-level transaction that the editing domain activates, it uses its factory to
create a validator that will validate the transaction when it commits, as well as tracking
the notifications that will be sent to pre- and post-commit listeners.  There are two kinds
of validator:  read-only and read/write, according to the nature of the transaction.
</p>

<blockquote>
	<img src="images/validator.png" alt="Transaction Validator API"/><br/>
	<font size="-2">[<a href="images/validator.svg">as SVG</a>]</font>
</blockquote>

<p>
Extensions of the editing domain may install their own validator factories to customize
their validators to set different options using the EMF Validation Framework's live
validation API.  For example, a client may want set specific constraint filters or provide
arbitrary client-specific data to validation listeners.  See the EMF Validation Framework
documentation for details.
</p>
<hr/>

<p>
<a href="https://www.eclipse.org/legal/epl-2.0/">Copyright (c) 2006, 2007 IBM Corporation and others.</a>
</p>
</body>
</html>
